Optimize array intersection functions for empty operands - #22831

How does it affect performance for the negative case when none of the arrays is empty?

@kamil-tekiela Thanks for the review. I reran the non-empty cases using 15 paired processes per scenario and repeated the measurements twice.

For very small arrays, the overhead ranged from roughly 0.5% to 5%, corresponding to only a few nanoseconds per call. With 100 or 10,000 elements, the differences were generally around 1% or less and were not consistent between runs.

Overall, the shortcut adds a small fixed cost to non-empty calls, which becomes negligible as the arrays grow.

I also don't like this. You are trading performance, not improving it. IMHO, the more common case is that none of the input arrays is empty, so your PR would actually worsen the performance in the most common case. Maybe it's something for optimizer, but I doubt it's worth optimizing this.

@Girgias MAY_BE_EMPTY_ONLY() should be accurate and folding the call would work, but the impact maybe limited

Thanks for the reviews. Agreed on both counts: the early exit adds a small fixed cost to the common non-empty path, and per @arnaud-lb an optimizer-level fold via MAY_BE_EMPTY_ONLY() would only cover operands that are statically known to be empty, where the impact would be limited anyway. Closing.